The invention relates to electronic design automation, and more particularly, to methods and apparatuses for rapid checking of design rules in a circuit layout.
Advancements in process technology have impacted integrated circuit manufacturing in at least two key ways. First, scaling of device geometry achieved through sub-wavelength lithography has facilitated packing more devices on a chip. Second, different process recipes have enabled manufacturing of heterogeneous devices with different threshold and supply voltages on the same die. A consequence of these improvements, however, has been an explosion in the number of design rules that need to be obeyed in the layout. Instead of simple width and spacing rules, modern fabrication technologies prescribe complex contextual rules that have to be obeyed for manufacturability.
The increase in the number of rules has complicated the task of creating design rule clean layouts, i.e., layouts that do not have design rule violations, Creating design rule clean layouts for digital circuit designs can be facilitated by the use of standard cell layouts as building blocks, and placement and routing tools that are extended to address the design rules.
Unfortunately, this approach usually does not work for analog. RF and custom circuit designs. Layouts for such designs are typically created manually using layout editors, and because of the number and complexity of the design rules, checking them was a laborious process.
A conventional design rule check (DRC) system requires a powerful two-dimensional geometry engine which supports geometric operations such as Boolean operations like AND, OR, NOT, XOR; sizing operations like grow/shrink horizontal/vertical/diagonal; other operations like merge, shift, flip, cut, smooth; as well as all-angle geometry for true Euclidean distance calculations. Individual rules are typically checked individually over an entire layout region. This is also true of individual rule values of same rule (e.g. a check against the minimum value for a rule, and another check against a preferred value for the same rule). Each check basically runs an independent sequence of geometry operations, and numerous passes through the layout region are required.
For example, a conventional series of operations to check a minimum spacing rule in a Manhattan only layout, might include steps of                Merge all same layer shapes into separate islands;        Grow all islands by half the minimum spacing value;        Perform an AND (intersection) operation among the islands; and        Draw DRC violation markers based on the resulting shapes of the AND operation.        
As another example, a conventional series of operations to check a minimum width rule in a Manhattan only layout, might include steps of                Merge all same layer shapes into separate islands;        Shrink all islands by (half the minimum width value epsilon)        Eliminate all resulting islands of zero area;        Grow back the resulting islands by (half the minimum width value+epsilon);        Perform a NOT operation between the original merged islands and grown back islands; and        Draw DRC violation markers based on the shapes resulting from the NOT operation.        
So long as a good geometry engine is available, the conventional DRC techniques are simple to code, at least for simple rules. They are also flexible and powerful if the geometry engine has a scripting API for relevant geometry operations, and it is relatively straightforward to massively parallelize the DRC process among numerous CRUs.
On the other hand, it can be seen that checking even simple design rules like those above is extremely expensive computationally. Massive parallelization usually is possible only for offline checks, which typically are performed only between layout iterations. Even then they often can require hours to complete. The conventional approach also suffers from roughly linear growth of the total run time with respect to the number of rules to be checked, with multiple values for a rule counted as separate rules. This makes it very hard to reduce the total run time without turning off selected rules. The conventional approach also suffers from linear growth of run time for individual rule checks, with respect to the length of the geometry operation sequence, i.e., the complexity of the rule. The conventional approach also involves separate checks for Euclidean measurements, and also requires extensive education and training in order to optimize the performance of the customer scripts.
The conventional approach becomes even more intensive at more advanced technology nodes, where many design rules are partially or fully defined on derived layers. Derived layers are not part of the layout itself, but rather are virtual layers defined by the design rule data set in order to simplify the statement of certain design rules. The design rule data set typically contains a derivation operator for each derived layer, that defines how to derive the shapes in the derived layer from the shapes in one or more parent layers. Derived layers are calculated by the design rule checker as part of the process of checking the design rules that reference them. Derived layers can even be defined recursively (i.e. one or more parent layers are themselves derived layers), rendering design rule checking at these technology nodes even more computationally intensive.
The manual layout editing process could be drastically facilitated if design rule checking could be performed in real time, that is, immediately after each geometric manipulation made by the designer. While some layout editors are able to do this, the checking can be sluggish and usually works only when some of the design rules are turned off.